Addressables 1.16.16 レポート

概要

そろそろこういうのをすべきタイミングだという感じになった。

参考にした公式資料

https://docs.unity3d.com/Packages/com.unity.addressables@1.16/manual/ContentUpdateWorkflow.html

ほか

宿題

こういうのがあったんだわ。 2018年の俺の記事。

Real World Addressables(WIP)

https://sassembla.github.io/Public/2018:07:10%2010-43-10/2018:07:10%2010-43-10.html

これに書いてあるこれじゃあ使えねーよ的なポイントを踏まえて、宿題として、どうなったかをみていく。

CatalogのDLに失敗したらどうなるの?

-> 自前で好きなタイミングでCatalogを更新できるようになった。

以前のように起動時に無理くりCatalogを取得しにいって、私通信に全く失敗しないので、、みたいなことはなくなった、、のか？

ローカルからデフォルトカタログを見出して云々ができてるので、そもそも平和な感じがある。

Catalogって何個も同時読みできるの？

-> Local/Remote Catalogsってあるから、内部にCatalog x Nを持ってて個別で更新できるんだろうと思っていたが、そうでもなかった。

やっぱ基本的には単一Catalogで、複数のプロジェクトからCatalogを持ち寄って(!!!!!)マルチカタログを実現しているっぽい。そんな暴力的な、、、

それはできるとは言わない、やらない方がいい。

Catalog更新する時、既にロードされてるAssetはどうなるの？ -> 高度なモード、としてなんかオプショナルなのが用意してある。

https://docs.unity3d.com/Packages/com.unity.addressables@1.16/manual/ContentUpdateWorkflow.html の、Unique Bundle IDs ってのに書いてある。

これは設定をいじるとABの名前自体に細工をしたりするんだと思うが、まあ、なんかそういう再生成処理が必要。

新規に生まれている制約

おそらくだけど、2018に自分がみた時よりも、オプションが相当増え、相当高度なことができるようになっている。

ぶっちゃけこれらの運用上の制約はどこにどんなのがどうあるか、というと、ドキュメントとUnityEditorの実装との両方にある。

パッとみた感じだが、次の疑問がある。

1. AAS上で、Catalogを更新すべきタイミングとはいつなのか、なんかこういうシーンを用意して更新するといいよ、とかがあると良さそうだがさて？

2. CatalogのIDをクライアントが得るのはどこからどういう方法がいいと思う？などのサジェストがない(ここになんらか運用まで影響を与える制約がありそうな気はする)

3. データ取得元のURLってまだUnityEditor経由のGUIにバインドされてるんだろうか？ちょっとよくわからんかった。

んでこれを知るには結構旅が必要で、UnityEditorのウィンドウでその旅の全てが行われるかと思うと、辛い。

なんでもEditorでやりすぎてる気がする。

想定されている運用

Addressablesは、今のところは、やっぱり簡易的なゲームで次のような運用スタイルを想定して作られているなーって思った。

1. Address(スロット)を元に、そこに何かをロードする、スロット or インデックスありきのシステム

2. 基本的には1つのカタログでやる、というオールオアナッシング方式、ちっさな変更でかい更新単位は辛い

3. データ取得URLがUnityEditor込みでbindされてるのに精神が耐えられる人向け

4. いざとなったらリソース更新のためだけにアプデ版をしれっとApple審査とかに通すメンタル

Autoyaの機能の7割くらいまではカバーできてる感じになった。

あとやっぱAddress機能のアンバランスさが目立つようになってきたなー。

名前の元になっている要素ではあるんだけど、Addressは正直どうでもいいというか、存在しようがしなかろうが嬉しさも悲しさも増減しない仕組みな気がする。

じゃあ俺は使うのか

ホビーであれば使うことがあるかもしれないが、ヘビーに、となると、求める運用スタイルが合わない。足りない上に、複雑。

そんでこの世界、こと運用において、運用自由度の大は小を兼ねる。なので使わない。

これは、「いつCatalogが更新されるかを毎度書かないといけない」「Catalogが基本やっぱ一個」「UnityEditorに凝集しすぎ」というのに起因する。

特にCatalogが1プロジェクトあたり1個が辛いなあ、、、無理、、、

あと、自動的に通信に介入して「リソース更新があったらやるよ」を意識せずに扱えるフレームワークがあれば、Addressablesはそれに食われた方が使いやすい。

そして、AddressablesはとにかくすべてをUnityEditorでやらせすぎる。

・ネットワークに干渉する機能はなく

・アップデートは自分で予定したコードを書かねばならず

・UnityEditorでそれらをセットするという見通しの悪さがある

こうなっちゃってる。Unityとしては正しいんだけどさ、俯瞰とかお手軽からは遠い。

結局リソース更新とはゲームやAppの運用なのだけれど、それを俯瞰的にこなすにはUnityEditorは狭すぎる気がする。みんなで見るとかも出来ないし。

これは作っているものにあんまり依存しない話だと思うが、開発者が楽をするためのAutomationと、運用が素敵になるためのOperationalityは両立しないといけない。

んでこれを、どんな運用する想定でゲーム作ってます！っていう情報を受けてからモノを作るわけでもない、固定の機構(Addressables)が叶えてくれると思う方がおかしい。

ただ、Addressablesは2018WIPと比べれば、そりゃもうよくなっている。

反面、機能の増加や責任の増加から、それを俯瞰するための窓の小ささがつっかえになっていて、全体像を把握するのが難しくなってんなーとも思った。

感想

UnityのAssetBundleは、なんか個人的にはギリギリの「こうする人もいますので、、」という線をだいたい全部超えた機構になっていて、あれがベースラインなのはとてもいい。

が、そこから上に、AutomationとOperationalityを両立した万人向けのものが作れるのか、というと、うへえーー難しそう、、ってなってしまう。

Addressablesはそれに挑んでる。

UCCD(Unity CloudContentDelivery)はこの辺めちゃくちゃ割り切っていて、

https://sassembla.github.io/Public/2020:09:11%2011-27-48/2020:09:11%2011-27-48.html

Web上でセットアップするGUI込みで大変よくできている、CDNのRailsという感想がぴったりな感じで、Webでセットアップから運用までが完結している。ファイルに触れもしねえ。

AddressablesもAddressables on Railsみたいな感じで、ブラウザでセットアップできるといいんじゃあねーの？って思ったりしている。

これは単純に、UnityEditorに何かやらせる量が多ければ多いほど、運用制約がコードとして凝集されてしまって、それの説明を探すのがしんどすぎるというのがあって、

ぶっちゃけAddressanbles on Railsみたいな、セットアップをブラウザでやる簡単版として設定をWebとEditorに分散すればいいんじゃあねーの？とか妄想している。(二度目)

だってWebから「はいこのバージョン解放～」とかやりたくない？そんでそのためのカタログとかはUnityEditor関係なくProjectから作って欲しいな、Web上で。

ABもそこでビルドしちゃいなよ。

どちらにしても「難しいのはAssetBundleではなく運用」な感じで、Appのを更新せずデータを更新するのを人間がどーやるかなので、

運用側をRailsにしていかないとパッともガッとも使いにくかろうな～というところがある。